fix: digest with passing filters are not aggregated #4992
Conversation
| @@ -33,6 +33,7 @@ export class QueueNextJob { | |||
| environmentId: command.environmentId, | |||
| organizationId: command.organizationId, | |||
| userId: command.userId, | |||
| job, | |||
There was a problem hiding this comment.
The conditions filter did not have the payload so all digests were created
| @@ -207,6 +208,27 @@ export class JobRepository extends BaseRepository<JobDBModel, JobEntity, Enforce | |||
| } | |||
| } | |||
|
|
|||
| if (filtered) { | |||
There was a problem hiding this comment.
If filtered, we want a new digest to be created, and not merged to an existing delayed digest
| }, | ||
| { | ||
| $set: { | ||
| status: JobStatusEnum.DELAYED, |
There was a problem hiding this comment.
@ainouzgali if this one was filtered out, why not marking it as skipped instead?
There was a problem hiding this comment.
also then digestResult: DigestCreationResultEnum.SKIPPED should be updated ;)
There was a problem hiding this comment.
We can. But then we won't have the execution details. We will be having a different flow for digest than for the other steps.
| private async digestSkippedExecutionDetails( | ||
| job: JobEntity, | ||
| filtered: boolean | ||
| ): Promise<void> { | ||
| const metadata = CreateExecutionDetailsCommand.getExecutionLogMetadata(); | ||
| await this.executionLogQueueService.add( | ||
| metadata._id, | ||
| CreateExecutionDetailsCommand.create({ | ||
| ...metadata, | ||
| ...CreateExecutionDetailsCommand.getDetailsFromJob(job), | ||
| detail: filtered ? DetailEnum.FILTER_STEPS : DetailEnum.DIGEST_SKIPPED, | ||
| source: ExecutionDetailsSourceEnum.INTERNAL, | ||
| status: ExecutionDetailsStatusEnum.SUCCESS, | ||
| isTest: false, | ||
| isRetry: false, | ||
| }), | ||
| job._organizationId | ||
| ); |
There was a problem hiding this comment.
Show execution details for a skipped digest - for backoff as well. We only showed 'step created'
What change does this PR introduce?
For a digest with filters that passes - it sent separate message for each trigger, instead of aggregating the events into one message.
Another problem fixed in this PR, is that a digest that is filtered (message should be sent immediately) was merged into a current delayed digest.
Why was this change needed?
Closes #4957
Other information (Screenshots)